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(Kbyte) magnetic bubble memory cassettes provide local 
storage for program software and data. 

As shown in figure 3 the AESL central system consists 
of two desktop chassis housings plus a terminal and line 
printer The main chassis contains a Multibus I cardcage 
plus peripherals consisting of a floppy drive, a tape drive, 
and a magnetic bubble memory cassette interface. The 
auxiliary chassis contains two 51 -megabyte (Mbyte) hard 
drives, one for software production files and the other for an 
integrated database containing battery servicing configura- 
tion files and data records. 

This report will discuss first how the requirements for the 
AESL led to the choice of BITBUS as LAN, and the con- 
figuration of the hardware components required to imple- 
ment it. Secondly, the report will describe the evolution of 
a NASA-developed protocol used to satisfy the AESL com- 
munications requirements. Finally, the report will outline 
the software elements which comprise this protocol and will 
give examples of typical BITBUS operations. 

Requirements 

The base line AESL physical requirements are for ten bat- 
tery stations to be installed in a servicing area adjacent to 
the operations room containing the central system. A daisy 
chained serial bus was selected to minimize the amount of 
wiring; for this reason a star configuration (either serial or 
parallel) was not considered. The total bus length required 
was 100 ft and a master-slave protocol was used to reduce 
the cost of the station controllers as much as possible. 

The AESL system functional requirement involving the 
greatest amount of LAN traffic is the exchange of files be- 
tween the central system integrated database and the bubble 
memories in the battery stations. During battery servicing, 
a battery station may ask for the download of a specifica- 
tion file related to a particular battery so that it may prop- 
erly configure the c ontro ller for a servicing run. The cen- 
tral system, on the other hand, must periodically upload data 
records generated during battery servicing so that they may 
be added to the database archives for access by interactive 
jobs. These files are typically 250-550 bytes in length and 
during periods of high activity may reach a rate of 50 file 
transfers an hour. 

A second functional requirement is the real-time mon- 
itoring of battery station activity from an interactive job. 
This involves passing blocks of status information from the 
selected station to the job running in the central system. 
The blocks run 500-600 bytes in length, but since they are 
only generated on demand, the total traffic volume is relat- 
ively small. 

The third functional requirement is for command capabil- 
ity to allow a battery technician to exercise remote control 
over operations at a selected battery station. This need may 
arise since the AESL is engineered to operate unattended, in- 
cluding overnight and weekend operations. The AESL mul- 
tiuser interface will allow authorized personnel to dial into 


the system over telephone lines to both monitor operations 
and exercise control if necessary. This capability would be 
used infrequently and the effect on bus loading is expected 
to be negligible. 

A final set of functional requirements involves house- 
keeping operations such as station polling, time synchro- 
nization, and station bubble memory garbage collection. 
Station polling must occur round-robin in such a way that 
no station waits more than 1 sec for servicing. Based on ten 
stations, the polling rate would be 10 Hz. Time synchroniza- 
tion involves passing a 32-bit date-time quantity from the 
central system to a station when requested (once a minute). 
Ten stations would generate ten such request-response mes- 
sage pairs a minute and constitutes perhaps 1 percent of 
bus loading. Station bubble memory garbage collection in- 
volves purging stale files after they have been uploaded to 
the central system. Such purge operations would normally 
be done by the system manager only during slack periods 
and thus would not adversely affect bus loading. 

Hardware Configuration 

Early in the AESL design effort it was decided that a LAN 
mechanized with BITBUS hardware and software compo- 
nents would meet all of the requirements previously dis- 
cussed, and would be highly cost effective as well. The 
SBX344A module was chosen as the interfacing hard- 
ware module since it is specifically designed to provide a 
BITBUS gateway to any single board computer (SBC) hav- 
ing a single board extension (SBX) connector. As shown in 
figure 4, the SBC used in the AESL central system is the 
286/12, while the SBC used in each of the ten battery sta- 
tion controllers (BSC) is the 86/35. Both board types have 
SBX connectors, and an SBX344A module will be installed 
on all 11 boards. The bus itself will consist of two runs of 
twisted shielded pair cable 100 ft in length, one pair for data 
and the other for the clock. 

The configuration of the 11 SBX344A modules varies 
slightly depending on which SBC is host All modules must 
be configured for 2.4-Mbit/sec synchronous operation and 
have socket U14 configured to receive a D2764A erasable 
programmable read-only memory (EPROM). The 286/12 is 
the master node and will be located at one end of the BIT- 
BUS. Its SBX344A module has been given decimal address 
28 and is configured with terminating resistors on both the 
clock and data pairs. The remaining SBX344A modules 
will be configured for addresses one through ten, and will 
not have terminating resistors installed. External terminat- 
ing resistors are used at the end of the BITBUS farthest from 
the master node. 

The SBX344A module as received from the factory has 
its 8044 microcontroller chip programmed with distributed 
control microcontroller (iDCM)-44 release 2.0 firmware. 
This firmware is a preconfigured version of the distributed 
control executive (iDCX)-51 release 2.0 which provides a 
single resident task 0 called the remote access and control 
(RAC) task. This firmware provides all the commands nec- 
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essary for operation of the AESL LAN, and therefore no 
additional iDCX-51 software is required. 

From the viewpoint of the iDCM-44 firmware, the 
SBC board which hosts the SBX344A module is consid- 
ered an “extension” which means the firmware communi- 
cates with the SBC through its parallel port (the firmware 
communicates with the BITBUS through its serial port). 
Most communications are from the master node’s exten - 
sion (the SBC286/12) to one of the slave node extensions 
(an SBC86/35). However, an extension can communicate 
with its own node using address OFFH or with a remote 
node (rather than the remote node’s extension) by setting the 
destination extension bit to 0 in the message header. When 
communication with a particular slave node’s extension is 
broken', tfie~286/f 2 communicates witfilthat slave nodexJP 
rectly (RAC command RESET_STATION) and with its own 
node to declare the slave node inactive (RAC command OF- 
FLINE). The SBC86/35 board at a slave node communicates 
with its own node during initialization in order to read its ad- 
dress jumpers (using RAC command READ JO at address 
OFFH) to identify its own particular station number. 

The iDCM44 firmware provides a default BITBUS mes- 
sage length of 20 bytes. Since each message has a 7-byte 
header, this leaves 13 bytes (or 65 percent) of the mes- 
sage available for data. When BITBUS was first consid- 
ered for the AESL, it was decided that a longer message was 
mandatory to improve the LAN performance when passing 
large blocks of data. Fortunately, the release 2.0 version 
of the iDCM-44 firmware has a feature (shown in fig. 5) 
called an initial data descriptor (IDD) which is invoked at 
SBX344A power-up. An IDD permits changing the default 
values for clock period, clock priority, and message length 
(RQSYSBUFSIZE), and also permits reserving a portion 
of memory so that it cannot be used to buffer messages. 
The firmware checks address 1000H to see if either pro- 
grammable read-only memory (PROM) or random access 
memory (RAM) has been installed in socket U14. If it finds 
the check pattern 0AA55H, it chains any initial data (and 
task) descriptors into the initialization sequence. 

All AESL SBX344A modules have a D2764A EPROM 
installed in socket U 1 4 which contains the IDD shown in fig- 
ure 5. The total available memory for iDCM-44 release 2.0 
is 108 bytes. On the advice of Intel Corporation this IDD 
was structured to redefine the message length to 54 bytes, 
thus allowing two messages to be buffered. This change has 
lowered the message overhead from 35 percent to 13 per- 
cent and has improved bus bandwidth considerably. The 
clock period and priority are left unchanged and no memory 
is reserved. 

Bus Protocol Evolution 

In the early stages of AESL software development 
(Glover, 1988b), the protocol shown in figure 6 was tested 
extensively. The destination task field of the BITBUS mes- 
sage header was used to specify 1 of 16 possible functions to 
be performed within the BSC. This protocol has two major 


disadvantages: (1) it is highly application specific and there- 
fore inflexible and (2) it does not permit concurrent com- 
munications with more than one central system job. For 
these reasons, a new approach was considered necessary 
even though the protocol functioned well and provided valu- 
able experience in the uploading and downloading of large 
segments of data using BITBUS message packets. 

The seco nd phase of protocol development took the ap- 
proach of structuring all bus traffic around the management 
of real-time multitasking executive (iRMX) objects in the 
slave extensions. The central system could create and delete 
mailboxes, could send and receive message segments at any 
desired mailbox, and could perform four operations on seg- 
ments: create, delete, upload, and download. Application- 
s' aspects of communications under this protocol are 
hidden within the segments being exchanged and concurrent 
processing is assured by each job having its own set of ob- 
jects. Fig ure 7 shows the steps involved in a master-slave 
exchange under this protocol. The weakness of this proto- 
col is that the master must either have a priori knowledge of 
the proper destination mailbox when initiating an exchange, 
or there must be agreed-upon conventions (such as use of 
null tokens) for accessing specific mailboxes created by 
the slave. 

The final phase of protocol development began with the 
ground rule that each slave would create two mailboxes 
which could be accessed by the master using certain des- 
tination task identifiers in the message header. One would 
be called the command mailbox, to which jobs in the master 
would send command segments (forcing some sort of ac- 
tion by the slave). The other would be known as the request 
mailbox, which the master would periodically poll to see 
if a requestor task within the slave had sent a request seg- 
ment (asking the master to take some action). This protocol, 
shown in figure 8, eliminates the need for the master to cre- 
ate and delete mailboxes, but essentially retains the other six 
operations of the purely iRMX object based approach previ- 
ously mentioned. For both approaches, concurrent process- 
ing ends after the command segment is sent to the command 
mailbox if there is only one task performing command ser- 
vicing. Similarly, slave requestor tasks must wait in turn if 
there is only one request servicing task doing the polling in 
the master. 

Battery Station Software Modules 

The AESL battery stations employ SBC86/35 boards run- 
ning a partial RMX I release 7 configuration consisting of 
n ucleu s, basic input/output system (BIOS), and a single user 
job as shown in figure 9. No device drivers are needed 
for either the SBX344A or the Linear Systems Ltd. clock- 
calendar module (LSBX) since only a single task within the 
user job interfaces to either device. 

The tasks involved with BITBUS operations are shown 
in figure 9 and of those, only the BITBUS task is applica- 
tion independent. The BITBUS task creates the command 
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mailbox and the request mailbox. The command servic- 
ing task waits for command message segments posted by 
the BITBUS task and if closed loop, generates a reply mes- 
sage. There are two requestor tasks in the AESL applica- 
tion which can send request segments to the request mail- 
box: one which occasionally requests files to be downloaded 
from the central system, and another which once a minute 
requests a date-time download for clock synchronization. 
This automatic synchronization is an important feature of 
any distributed system because it permits a single master 
clock to pass along all time changes to the slaves, as well 
as correcting normal drift. In the AESL, synchronization 
is especially important because file names for data files are 
generated from the date-time at the instant of the snapshot. 

When the BITBUS task is created, the address jumpers 
on the SBX344A board are read and that address becomes 
the station number for that extension processor. Files sent 
to the central system are tagged with this station number so 
the source can be identified. The BITBUS task is configured 
as a polling task which checks the SBX344A module every 
20 ms to determine if any messages have been received, and 
if so, generates and sends immediate reply messages. If no 
traffic is received for 10 sec, a flag is set which inhibits re- 
questor tasks from sending requests to the request mailbox. 

Central System Software Modules 

The AESL central system is a 286/12 system 310 with 
5 Mbytes of zero wait state RAM running a fully configured 
iRMX II.3 operating system. Multichannel communication 
boards allow the coexistence of several interactive jobs us- 
ing round-robin scheduling and 50-ms windows. As shown 
in figure 10, there are two NASA developed device drivers 
linked to the BIOS and two I/O jobs created by the extended 
I/O (EIOS), The clock device driver and the clock I/O job 
relate to a battery-powered clock-calendar module used for 
master timekeeping, and are not involved with the BITBUS 
LAN in any way. 

The BITBUS device driver was designed to recognize all 
BIOS functions except F$READ, F$ WRITE, and F$SEEK. 
The function F$ATTACH$DEV causes the SBX344A mod- 
ule to be reset, while FSDETACHSDEV, F$OPEN, and 
F$CLOSE simply return E$OK. The function FSSPECIAL 
accepts only a subfunction code of 800 1H and interprets it 
to mean a BITBUS message transaction where the auxiliary 
pointer points to the BITBUS message to be sent: 


declare 


bitbusSmsg 

structure ( 

link 

word. 

length 

byte, 

flags 

byte. 

node 

byte, 

taskSids 

byte, 

cmdSresp 

byte, 

dat (248) 

byte ); 


The BITBUS device driver would be invoked as follows: 

call rq$s$special ( bitbus$connection, 

8001 H, 

@ bitbusSmsg, 
nil, 

(©exception ) ; 

The response message is written on top of bitbusSmsg so 
it is imperative that the data field be long enough for the 
longest possible response. 

The polling T/O job is a high priority job which first reads 
the contents of the file :CONFIG:STATIONS and builds a 
list of stations to be polled. Thereafter it iterates at 10 Hz, 
polling the set of all stations thought to be active and for 
each such scan polls one station from those thought to be 
off-line. Each poll causes the status of the station to be up- 
dated depending on whether or not a reply was received. If 
a reply was received and a request for service was fetched, 
the request is immediately processed and the response is 
sent back. 

The interactive jobs which involve sending commands to 
a station are linked to a set of routines which provide inter- 
leaving of bus traffic using RQ$S$SPECIAL calls as previ- 
ously shown. A standard interface to these routines has been 
developed which employs a structure of the following form: 


declare 


commandSmsg 

structure ( 

node 

byte, 

function 

byte, 

count 

word. 

exception 

word. 

actual 

word. 

bufferSptr 

pointer, 

stringSptr 

pointer ) ; 


The top-level command routine is invoked as follows: 


call command$io ( @command$msg ) ; 

This routine is necessarily application-dependent but in 
turn it is linked to a number of supporting routines which are 
solely protocol-dependent. For a given application, all inter- 
active jobs would be bound to the same command routine 
(and supporting routines) which would interpret the func- 
tion code and perform the proper BITBUS I/O operation. 

Bus Operations 

As stated earlier, bus operations can be initiated at one 
of two points: a central system job which commands a par- 
ticular station to take some action, or a station task which 
sends a request segment to its request mailbox. All test- 
ing to date has been performed with a single station: the 
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engineering prototype battery bench (which was given ad- 
dress 27). Stress tests have been performed where three 
interactive jobs have simultaneously commanded the sta- 
tion to upload a large status segment. Some slight delay is 
noticed occasionally in the response time of the interactive 
job’s display, but these delays are generally less than 2 sec. 
File transfers of 250 to 550 bytes have been tested exten- 
sively and delays are generally 2 to 3 sec. A large part of 
this delay is caused by the slow response time of the mag- 
netic bubble cassettes in the BSC. 

Figure 1 1 shows the elements involved in a typical closed- 
loop command sequence. The circled numbers in figure 1 1 
correspond to the following steps: 

1 . The interactive I/O job calls the command routine with 
a function code involving closed-loop command, 

2. A command segment is created and its token 
is returned, 

3. The command segment is filled using multiple down- 
load transmissions, 

4. The command segment is sent as a closed-loop com- 
mand, a reply mailbox is created, and its token 
is returned, 

5. The command routine inserts an appropriate time de- 
lay for the reply segment to be generated and sent. 
The command segment is deleted by the slave’s 
command servicing task after the reply segment has 
been generated, 

6. The command routine begins to solicit the reply seg- 
ment token and repeats until received. The reply mail- 
box is deleted by the slave’s BITBUS polling task 
after the reply segment token has been successfully 
picked up, 

7. The reply segment is emptied using multiple upload 
transmissions, 

8. The reply segment is deleted, 

9. The information is passed back to the interactive job. 

To enhance the performance of the protocol, command 
segments are downloaded and reply segments are uploaded 
only if the information will not fit into the available free 
space in the BITBUS message. The amount of free space 
in the message varies from 39 to 45 bytes depending on the 
message type (fig. 8). When the information will fit into 
this free space, the presence of immediate data is signalled 
by the command or reply segment token being set equal to 
the value selector$of(niI). Thus whenever a message is re- 
ceived which involves a segment, the token must be checked 
and immediate data used when appropriate. In the case 
of command information, the slave’s BITBUS polling task 
will create the command segment when necessary to receive 


the immediate data. In the case of reply information, the 
BITBUS polling task will send the information back as im- 
mediate data whenever possible and delete the reply seg- 
ment. Otherwise, the recipient is responsible for deleting 
the reply segment after it has been uploaded. 

Figure 12 shows the logic employed in the polling I/O 
job. As described earlier, the job fetches the file :CON- 
FIG:STATIONS during initialization and builds a polling 
list It also creates a status array which indicates whether 
a station is believed to be "asleep” or "awake”, and initial- 
izes it to all asleep. All awake stations (if any) are polled 
once and then the next station from those classified asleep is 
polled. One station is polled every 100 ms and its status is 
updated; this polling rate is a compromise between servicing 
delay and central system processor loading. If a reply was 
received and a request for service was fetched, the request 
is immediately processed and the response is sent back. For 
a STATIONS file consisting of 

1,2,3,4,5,6,7,8,9,10,27 

the polling rate for the single active station 27 is approxi- 
mately 85 times a minute. This rate could be expected to 
drop to 60 a minute with ten stations active. 

Concluding Remarks 

In late 1990 the NASA Ames-Dryden AESL will become 
operational as a semi-automated facility for the servicing of 
aircraft batteries. This facility will be a distributed Multi- „ 
bus I system with a central system running iRMX II and ten 
operator positions running iRMX I linked by a BITBUS net- 
work. A prototype network, consisting of the master node 
and a single slave node, is now operational and has proven 
highly reliable at 2.4 Mbit/sec over 100 ft of bus. The BIT- 
BUS message length has been increased to 54 bytes by tak- 
ing advantage of the IDD feature in the latest release of the 
BITBUS OCX. A NASA developed protocol permits a mix 
of interactive and I/O jobs executing within the central sys- 
tem to communicate concurrently with any of the servicing 
positions. This protocol makes possible BITBUS applica- 
tions beyond distributed control to intersystem networking, 
including file transfers and other communications involving 
large segments of data. 
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Figure 2. Battery station bench. 
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Figure 3. Central system console. 
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Figure 4. BITBUS hardware configuration. 


Address 

Contents 

Description 

1000H 

DW 0AA55H 

; check pattern 

1002H 

DWO 

; block type (IDD) 

1004H 

DW 0 

; RQCLOCKTICK (no change) 

1006H 

DBO 

; RQCLOCKPRIORITY (no change) 

1007H 

DB 54 

; RQSYSBUFSIZE (new value) 

1008H 

DBO 

; reserved memory (none) 

1009H 

DWO 

; next block (none) 


Figure 5. Initial data descriptor. 
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Figure 7. iRMX object based protocol. 
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Task 


Function 


1 Issue open-loop command 

2 Issue closed-loop command 

3 Retrieve closed-loop command reply 

4 Check service request mailbox 

5 Deliver service response 

6 Create segment 

7 Delete segment 

8 Upload from segment 

9 Download into segment 


Send to slave extension 

commands segment $ token 
immediateSdata (45) byte* 

commands segments token 
immediateSdata (45) byte* 

reply SmailboxS token 
- nothing - 


service$mailbox$token 
servi ce$ segment $ token 
immediateSdata (43) byte* 

segmentSsize 

segments token 
offset 

segments token 
[ commands response^# ] 

offset 

segment St oken 
dataSbytes (#)byte 
[ commands response=# ] 

= selector$of (nil) 
Figure 8. Final protocol design. 


*If immediate data appended, segment Stoken 


Receive from slave extension 

status 

status 

reply SmailboxS token 
status 

reply S segment Stoken 
reply S segments size 
immediateSdata (41) byte* 

status 

request Ssegment Stoken 
request SsegmentS size 
service SmailboxS token 
immediateSdata (39) byte* 

status 


status 

segment Stoken 

status 

status 

dataSbytes (#) byte 
status 
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Figure 10. Central system software. 
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Slave extension 


Temp orary RMX o bjects 

. ©i^celve^ 

©_Empty^ 

(5) Delete 



Create (D^ 

Fill (D Command 
lend"®*' segment 


Create J® 
Send © 
Delete J^) 


Reply Y 
mailbox L 


_®Recelye 

(5) Send 



(.ISslS 

Delete 



®J>eate 

g^jnu. 

(s)_Send_ 


Figure 11. Typical closed-loop command sequence. 
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